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SYSTEM AND METHOD FOR MANAGING 
SECURITY OBJECTS 

CROSS REFERENCES TO RELATED 

APPLICATIONS 5 

U.S. patent application Ser. No. 09/240,720, entitled 
"System and Method for Network Address Translation Inte- 
gration With IP Security"; Ser. No. 09/239,694, entitled 
"System and Method for Dynamic Micro Placement of IP ]Q 
Connection Filters"; Ser. No, 09/240,483, entitled "System 
and Method for Central Management of Connections in a 
Virtual Private Network; and Ser. No. 09/240,718, entitled 
"System and Method for Dynamic Macro Placement of IP 
Connection Filters", filed concurrently herewith are J5 
assigned to the same assignee hereof and contain subject 
matter related, in certain respects, to the subject matter of the 
present application. The above-identified patent applications 
are incorporated herein by reference. 

BACKGROUND OF THE INVENTION 20 

1. Technical Field of the Invention 

This invention pertains to data security. More particularly, 
it pertains to the creation, deletion and retrieval of security 
connection objects and the querying of cryptographic ser- 25 
vices. 

2. Background Art 

It is currently state of the art of the Internet to create 
Virtual Private Networks (VPNs) using Internet Protocol 30 
Security (IPSec). However, there exists no standard nor 
current implementation for configuring and implementing 
the connection of systems in this Internet environment, such 
as between systems using the Transmission Control 
Protocol/Internet Protocol (TCPIP) and systems using the 3S 
Internet Protocol Security (IPSec). Typically, graphical user 
interfaces (GUIs) are provided that configure data security 
policies only. There is, therefore, a need in the art to provide 
a connection model and GUI for configuring the connection 
of disparate systems, particularly in an Internet environment. 4Q 

With the onset of network computing came the need to 
insure secure connections between networked computers. 
Usually companies resorted to establishing private networks 
to do this, and at considerable expense. However, as this 
trend of Network Computing continues to evolve, it is 45 
necessary to extend secure communications within the enter- 
prise and to utilize the public networks. Driving factors 
include the need for mobility, company mergers and 
acquisitions, and the usual 'improving the bottom line'. 
Virtual Private Networks (VPNs), in this context, allow 50 
customers to use existing private or public networks, includ- 
ing the Internet, to establish secure connections between 
other businesses, branch offices, and remote users. One 
problem with VPNs is they are usually implemented via 
proprietary techniques, such that interoperability is limited 55 
to single vendor solutions. The IETF now has working 
groups and draft standards which will allow a more uniform 
VPN solution across vendors that implement to those stan- 
dards. IP Security (IPSEc) and Internet Security Association 
Key Management Protocol (IS AKMP) are examples of these $0 
standards and these are the standards used in the preferred 
embodiment of the invention. 

Current systems apply static, predefined filter rules (SPD 
entries, in RFC2401 terms) to a system interface. WheD 
attempting to negotiate with a remote system, if the client 65 
identifiers I Dei and IDcr from the remote system do not 
match exactly an existing filter rule, the negotiation is 



,562 Bl 

2 

unsuccessful. IDci and IDcr are the identifiers for clients of 
Security Associations (SAs), where ci refers to client initia- 
tor and cr to client responder. An SA is an IS AKMP 
(sometimes referred to as the Internet Key Exchange (IKE), 
which defines the IPSec domain of interpretation of the 
ISAKMP framework) unidirectional security protocol spe- 
cific set of parameters that defines the services and mecha- 
nism necessary to protect traffic between two nodes. 
Consequently, there is a need in the art for enabling accep- 
tance of previously unknown IDci and IDcr values from a 
remote system. Further, current implementations may have 
a filter rule for all IP traffic between a local host and a given 
subnet through a remote gateway. If so, the only connection 
allowed is for this set of IP traffic, and if the remote host does 
not have a corresponding filter rule, no connection can be 
established. There is, therefore, a need in the art for dynami- 
cally generating, loading and managing multiple IPSec filter 
rules (SPD entries) for traffic between a local host and a 
given subnet through a remote gateway. 

Current system provide ISAKMP phase I and phase II 
connections. A phase I connection is an ISAKMP-to- 
ISAKMP secure connection used to negotiate keying mate- 
rial for phase II connections. A phase II connection is the 
actual IPSec connection to secure IP datagrams. Usually, a 
phase I connection is managed in a similar manner to a phase 
II connection, in that it is initiated, refreshed, and possibly 
scheduled independently. There is a need, therefore, in the 
art for enabling ISAKMP phase II driven phase I 
connections, such that unnecessary IKE traffic is avoided by 
only creating or refreshing a phase I connection if there is an 
active phase II connection that currently requires it. 

Currently, filter rules are written statically with pre- 
defined IP selectors (IP addresses, port numbers, and trans- 
port protocol). However, when dealing with a dynamically 
assigned IP address from a third party (such as an Internet 
Service Provider, or ISP), there is no way currently of 
knowing what IP address to configure in the rules, particu- 
larly for handling different security policies for different 
hosts (users). There is, therefore, a need in the art for 
enabling connection filter rules to be generated and loaded 
dynamically at negotiation time, and thus handle remote 
initiating hosts with dynamically assigned IP addresses. 

It is a further object of the invention to provide a system 
and method for creating, maintaining, deleting and retriev- 
ing VPN policy objects. 

It is a further object of the invention to provide a system 
and method for enabling acceptance of previously unknown 
IDci/IDcr values from a remote system. 

It is a further object of the invention to provide a system 
and method enabling dynamic generation, load, and man- 
agement of multiple IPSec filter rules. 

It is a further object of the invention to provide a system 
and method enabling ISAKMP phase II driven phase I 
connections. 

It is a further object of the invention to provide a system 
and method enabling handling of remote initiating hosts 
with dynamically assigned IP addresses, that may have 
differing security policy requirements. 

It is a further object of the invention to provide a system 
and method providing flexibility in policy definition in the 
areas of dynamically-assigned IP addresses, remotely- 
defined ISAKMP client IDs (IDci/IDcr), and separation of 
ISAKMP Phase I (key management) policy information 
from ISAKMP Phase II (data management) policy informa- 
tion. 

It is a further object of the invention to provide a data 
model for representing and abstracting IPSec/ISAKMP- 
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based VPN configuration information for an IPSec-capable 
computer system in a virtual private network that (1) allows 
for each customer-generated customer-ordered security 
policy database (SPD) entry, multiple VPN connections to 
be dynamically established (these connections may or may 
not have been previously defined); (2) allows for a data- 
security -policy-driven approach to rekeying (via ISAKMP) 
where (a) the key management connection (i.e. the secure 
connection used to exchange keying material for the data 
connections) is created and maintained by security policy 
and on an on-demand basis by data connection activity, and 
(b) the key connection security policy is determined solely 
by the identity of the remote connection endpoint; (3) allows 
for dynamically establishing VPN connections with different 
security policies and other attributes, based solely on an 
unfixed IP address (e.g. a user ID) — these connections may 
or may not have been previously defined. This aspect is used 
for supporting systems with dynamically-assigned IP 
addresses that wish to establish a VPN connection with the 
local system. 

SUMMARY OF THE INVENTION 

In accordance with the invention, a data model is provided 
for abstracting customer-defined VPN security polity infor- 
mation. By employing this model, a VPN node (computer 
system existing in a Virtual Private Network) can gather 
policy configuration information for itself through a GUI, or 
some distributed policy source, store this information in a 
system -defined database, and use this information to 
dynamically negotiate, create, delete, and maintain secure 
connections at the IP level with other VPN nodes. 

Other features and advantages of this invention will 
become apparent from the following detailed description of 
the presently preferred embodiment of the invention, taken 
in conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a high level system diagram illustrating initiator 
and responder nodes. 

FIG. 2 is a high level system diagram illustrating the VPN 
policy database of FIG. 1, in accordance with the preferred 
embodiment of the invention. 

FIGS. 3A through 3D, arranged as illustrated in FIG. 3, 
are an object notation representation of the preferred 
embodiment of the invention. 

BEST MODE FOR CARRYING OUT THE 
INVENTION 

In accordance with the invention, a data model is provided 
for abstracting customer-defined VPN security polity infor- 
mation. By employing this model, a VPN node (computer 
system existing in a Virtual Private Network) can gather 
policy configuration information for itself through a GUI, or 
some distributed policy source, store this information in a 
system-defined database, and use this information to 
dynamically negotiate, create, delete, and maintain secure 
connections at the IP level with other VPN nodes. 

Referring to FIG, 1, a Virtual Private Network Connection 
Model (VPNCM) 14, 15 exists as a database, or other 
persistent storage medium, on each node 18, 19 in the VPN 
and executes under control of IKE (an ISAKMP application) 
and/or some other connection manager application 16, 17 
and IPSec 202, 203 on each of initiator node 18 and 
responder node 19, respectively. These nodes 18, 19 may be 
host or gateway nodes, or systems, and are referred to as 
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connection endpoints. Once a connection is created, filter 
rules (or SPD entries) and Security Associations (SAs) are 
loaded into the IP stack in the kernal 200, 201 to protect the 
connection's traffic as it passes through the stack. In a 
preferred embodiment of the invention, the VPN Conn 
Model is implemented as a database and is used by VPN 
Conn Mgr. IKE may be optional, since manual connections 
may be the only type configured. Initiator and responder are 
ISAKMP terms. Line 211 represents ISAKMP Phase I 
negotiations and line 212 represents ISAKMP Phase II 
negotiations. Phase II is an ISAKMP term for the negotiation 
of keys to protect the actual user data (i.e. the real VPN 
connection). This is in contrast to Phase I, which is the 
negotiation of keys for a ISAKMP/ISAKMP 18/19 connec- 
tion to protect Phase II negotiations. Line 213 represents the 
resulting VPN connection protected by an IPSec. 

The preferred embodiment of the invention calls for IP 
Security (IPSec) 202, 203 protocols (IETF RFC 2401 et al.) 
as the means of data protection and, optionally, Internet 
Security Association Key Management Protocol (ISAKMP) 
(IETF RFC 2408 et al.) for the means of maintaining the 
keys used by the negotiated IPSec protocols. 

In accordance with the preferred embodiment of the 
invention, a connection model is provided for describing a 
connection policy between systems, such as between sys- 
tems using the Transmission Control Protocol/Internet Pro- 
tocol (TCPIP) and Internet Protocol Security (IPSec) to 
protect their datagrams. This preferred embodiment has 
been designated the Virtual Private Network Connection 
Model (VPNCM), and provides a way to represent connec- 
tions in a Virtual Private Network (VPN). The model 
abstracts common information about these connections, and 
allows multiple connections to be based on a single con- 
nection definition. Furthermore, these connection definitions 
reference data security policies that describe how the traffic 
in a connection is protected. This enables multiple connec- 
tion definitions to reference relatively few security policies. 
Systems participating in VPNs may have IP addresses 
dynamically assigned. The preferred embodiment of the 
invention (VPNCM) accounts for connecting to a remote 
system that has a dynamically-assigned IP address by using 
deferred selectors. 

While it is currently within the state of the art to create 
Virtual Private Networks using Internet Protocol Security 
(IPSec), the Request For Comments (RFCs) and Internet 
Drafts for IPSec are only concerned with the lower layer of 
IP architecture, key exchanges, cryptographic algorithms 
and such. There is not standard for configuration and imple- 
mentation of the connection of systems. 

Referring to FIG. 2, VPN policy database 14, 15 is 
illustrated, with an instance al each of initiator node 18 and 
responder node 19. Each VPN policy data base 14, 15 
includes deferred selectors component 310, connection defi- 
nition 26, connection 52, manual connection component 
312, remote connection endpoint attributes component 314 
including phase 1 processing component 316, and phase 2 
processing component 318. Each of these VPN policy data 
base 14, 15 objects will be further described in connection 
with FIG. 3. 

User client pair 52 has a 1:1 correspondence to a con- 
nection (element 140, FIG. 9 of copending application Sen 
No. 09/240,483), and represents and defines the attributes of 
a connection which can be instantiated (or started). When 
started, connection 52 gets from connection definition 26 
information configured by a user by way of an anchor filter. 
Connection definition 26 defines how datagrams which 
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match the anchor filter are to be protected. See copending nection attributes 314 with a phase I negotiation policy in 

patent application Ser. No. 09/240,718 and 09/239,694 for a phase I processing component 316. 

description of anchor filters and their use with connection In order to enable handling at responder node 19 of 

filters. User Client Pair 52 defines connection properties and, remote initiating hosts 18 with dynamically assigned IP 

with connection definition 26 provides the information 5 addresses, there is provided at responder aode 19 policy 

required to instantiate a connection. In so doing, if keying is database 15 connection definitions 26 for identifying 

static, then manual connection component 312 is accessed ISAKMP phase II negotiation policies in phase II processing 

for additional information and if keying is dynamic, addi- component 318, anchor filters 20 (FIG. 3A) for defining the 

tional information is accessed from phase II processing datagrams that may be assorted with a remote host 18 

component 318. For both static and dynamic keying, user 10 using dynamically assigned IP addresses, and deferred selec- 

client pair 52 contains a pointer to remote connection tors "J? 0 ™ 1 310 providing a one to many mapping from 

endpoint attributes component 314 to find the local endpoint an f anchor 20 to connection definitions 26. 

ID and related attributes, including those of phase I pro- In accordance with the preferred embodiment of the 

cessing component 316. invention, previously unknown client ID pairs (IDci and 

T , , iL . , . , IDcr values) are accepted from a remote system. The user 

In the case where this local system 19 is responding to 15 J J- _ nn n „„. 

. ... . ^ io • * 10 •« * j , m ■ writes as few as one filter rule (also referred to as an anchor 

initiator system 18, initiator 18 will provide a client ID pair , x c 4 , , t - TD t ~ > . , . , , . ., . 

•r • ,u , f to . «: *u * rule) for the subset of IP traffic to be protected, similar to 

specifying the set of IP traffic that the connection being c J enUonal filter Ho wever, this anchor filter rule, by 

proposed will protect ^^^^ e f^^ way of its association with a connection definition, is not 

VPN policy database 15 and checks the connection defim- * ^ associations (SAs) will be 

tions 26 therein to determme if the clien ID pair provided 20 J traffic defined by the anchor rule, 

by iniuator 1 defines a proposed set of IP traffic (datagrams) * ^ * {q and 

which is a subset of the IP traffic associated with a connec- what y ^ of ^ IDg tQ a i ept Connection filters 

Uon definition 26 and which, therefore, responder system 19 ^ ^ ^ dynmi J^ based on cithcf 

is conngured to protect. bcally define(J connections (user client pair o5 j ects 52 ) f 

User Client Pairs 52 map 1:1 to connections that are IDci/IDcr from a remotc svstenij or from an IP packet (for 

defined to be initiated locally. When initiating a dynamic Qn demand connection). If a remote syste m offers client IDs 

connection, the keying attribute in connection definition 26 ^ say> Qnly TCp tfaffic between thc bcal host and a given 

of the VPN policy database 14 at initiator node 18 will subnetj connect ion filters for that traffic only would be 

indicate dynamic. Consequently, initiator 18 will negotiate gcnerated and loaded> with all other traffic bctwcen the local 

with responder 19, defined by the remote endpoint ID 113 of host and the gWen gubnet discarded> 

the user client pair 52 for the connection being started. Furthef fa accordance with the ferred embodiment of 

Responder node 19 will obtain local client ID «d remote the ISAKMp ^ u ^ ^ , connections 

client ff) attributes from initiator 18 as part of ISAKMP afe enabled ^ ^ a j connection fe onl crealed or 

Phase II negotiation and use those IDs to select the con- . f thcrc . g an activc n connection that 

nection definition 26 from responder database 15 that requires it. This reduces unnecessary IKE traffic. Also, phase 

defines the connection for the responder side. j s 4 ccurity policy and other attributes arc based ^My on the 

Manual connection component 12 provides information remote endpoint and no t on the phase II traffic being 

for manual (i.e., static) security associations (SAs), which ultimately protected, thus easing setup and policy definition, 

information describes such attributes as encryption and ^ Further> in acc0 rdance with the preferred embodiment of 

authentication procedures, and must be hand coded by the ^ invention? remote initiating hos ts with dynamically 

user, with mirror images on both initiator 18 and responder ^ d [p addrcsses arc handled through the usc of 

19 in order for a manual tunnel to work over connection 213. deferred ^ ag ^ as Qne anchor ^ CQn , 

Phase II negotiations 212 occur across a phase I connec- ncc tion filter rules can be generated and loaded dynamically 
tion 211 and result in a VPN connection 213 which is 45 at negotiation time. Negotiation is performed using a non- 
protected by an IPSec. IP-type selector, such as user@FQDN, for both phase I and 

In order to enable acceptance at responder node 19 of a phase II (whereas phase II negotiations are usually per- 

previously unknown client ID pair (IDci/IDcr) from initiator formed using IP-type only client IDs). Following successful 

node 18, a connection definition 26 is provided in database negotiation and authentication via IKE, the remote host IP 

15 for determining if the client ID pair is acceptable to 50 address for the filter rules is determined by the IP packet 

responder 19, and if so, an ISAKMP phase II negotiation source address. 

component 318 provides a policy for negotiating this client Referring to FIG. 3, the preferred embodiment of the data 

ID pair. model of FIG. 2, designated VPNCM, is set forth in object 

In order to enable dynamic generation, loading and man- notation. In the embodiment of FIG. 3, deferred selectors 

agement of multiple IPSec filter rules (i.e., connection 55 component 310 of FIG. 2 is implemented by deferred 

filters), a connection definition 26 is provided at responder selectors 22 and deferred selectors list 24; manual connec- 

node 19 for selection by either a user client pair 52 or a client tion component 312 is implemented by static ESP SA pair 

ID pair (IDci/IDcr) received from a remote initiator for 48, static AH S A pair 46 and static key 50; remote connec- 

identifying pertinent granularity attributes. These granular- tion endpoint attributes 314 is implemented by remote 

ity attributes define the subset of IP datagrams that can be 60 endpoint ID group 32, local endpoint ID 34, NAT pool 38, 

associated with any one connection instantiated from this and IP address 54, and also including in phase I processing 

connection definition 26. component 316, key management security policy 36, initia- 

In order to enable ISAKMP phase II driven phase I tor key management proposal 42, responder key manage- 

connections, whereby a phase I connection is only created or ment proposal 40, key management transform 44 and pre- 

refreshed based upon phase II connection activity, a refer- 65 shared key 56; and phase II processing component 318 is 

ence pointer (represented by line 41, FIG. 3B) is provided implemented by security policy 58, initiator proposal list 60, 

for associating a remote endpoint identifier in remote con- responder proposal list 62, proposal 64 and transform 66. 
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The notation used on the data model is the Object Model Some databases have their objects customer-ordered and 

Technique (OMT) notation, and can be found in "Object- therefore also support referencing objects by the ID(s) 

Oriented Modeling and Design", by Rumbaugh et al. In associated with objects of that database (a pair of client 

accordance with OMT notation, the boxes represent data identifiers (client ID pair) in the case of connection 

objects, showing their type (e.g. Connection Definition) and s definitions, and a single ID in the case of remote ID groups), 

the attributes associated with this type of object. The lines on a first applicable object basis. Client ID pairs define a 

represent association, specifically references. An arrowed subset of IP traffic and are made up of the ID of a local 

line is a one-way reference. A line with no arrows implies a systera ( or group 0 f systems), a local port, the ID of a remote 

two-way reference. References are usually handled by keep- sys(em (or group of systems ), a re m 0 te port, and a transport 

ing the name of the referenced object in the data of the protocol ( e , g . TCP). Client ID pairs are sometimes referred 

references For example, a Security Policy object has a (0 as Data End inls (in contrast t0 connectjon endpoints). 

reference to one ImUator Proposal List object and a refer- when refcrend customer . ordercd objects in this way, the 

ence to one Responder Proposal List object, but neither of ,. t . . & . . . . t . ATiJ J ™ _ t \\, t 

the Proposal List objects 'know' who holds references to ob J ects ar f in onlcr by Ite API. The to object that 

them (hence the arrowheads). The dots (or lack of) show 15 ^socuted with a superset of the input IDs is returned, 

multiplicity. No dot implies one and only one reference. An ™ In accordance with the preferred embodiment of the 

open dot implies either no reference or at most one refer- model, the following databases are provided: deferred selec- 

ence. The black dot means any number of references (i.e. 0 tors 22 database, including name field 81 that is used in a 

or more). A black dot with numbers means only those single system-wide Deferred Selector List; connection defi- 

number of references are allowed (e.g. 1+means one or nitions database 26, including name 82, selectors 83 (copied 

more; 2,4 means either 2 or 4). For example, a connection 20 from associated anchor filter 20), local endpoint role 84 

definition may or may not have a reference to a security (gateway or host), remote endpoint role 85 (gateway or 

policy (depending on the keying attribute being dynamic), host), connection granularity 86, initializer 87 (local, 

but if it does it only has one reference (hence the open dot). external, both), keying 88 (static or dynamic), lifetime 89, 

On the other hand, any number of connection definitions NAT local client 91 (server hiding:boolean), and NAT 

may reference a particular security policy (hence the black 25 remote c]ient 92 (boolean) fields, and any other information 

d°0* common to any connection protecting any portion of IP 

Anchor filters 20 are provided to indicate to the system traffic specified by the selectors; remote endpoint ID groups 

that certain IP traffic is to be protected using IPSec. These database 32, including a name 96, and a list of IDs 108; local 

filters 20 reference a connection definition (CD) 26 that endpoint IDs 34> including a name and an ID; key manage- 

descnbes the role of the endpoints (host or gateway), and 3Q men( securit Udes database 36 includm name 97 

other connection information There are two ways to estab- ISAKMp iniliaUzer mode 9g (main/aggressive) 

hsh a connection between systems: initiate the negotiation of , , , nn , . , . v ~ °° ^ TA 4> 
j * *l r ** an d responder mode 99 (main/aggressive/*) fields; NAT 
a connection, or respond to the negotiation of a connection. , . . ,« . , j. j ,. ^™ 
In the case of connections with static keys (i.e. Connections a ^ ress Pools da abase 38, including a name and a list of IP 
that do not manage keys via IKE), both connection end- addresses 100; key management proposals database 42, 
points are said to initiate the negotiation of the connection, 35 including name field 102; key management transforms data- 
even though no actual negotiation takes place. Initiators of basc including authentication mechanism 103, hash 
connections between systems using this connection defini- algorithm 104, encryption algorithm 105, pseudo-random 
tion (CD) 26 require a User Client Pair (UCP) 52 for each function, lifetime, lifesize, key length, and DH group 106 
connection that it can initiate. There may be a multiplicity of fields; static authentication header security association (SA) 
UCPs 52 referring to a single CD 26. CDs 26 also have a 40 pairs database 46, including name, inbound and outbound 
reference to the Security Policy (SP) 58 necessary for this IPSec security policy indices (SPIs), authentication 
connection. There may be a multiplicity of CDs 26 referring algorithm, encapsulation mode (tunnel/transport), and key 
to a SP 58. For systems that derive their IP address rounds; static encapsulating security payload (ESP) security 
dynamically, which is usually the case for systems attaching association pairs database 48, including name, inbound and 
to an Internet Service Provider (ISP) and that want to 45 outbound IPSec security policy indices (SPIs), encryption 
establish VPN connections to their home gateway, the home algorithm, authentication algorithm, encapsulation mode 
gateway can use deferred selectors 22 to associate an unre- (tunnel/transport), and key rounds; static SA keys database 
solved identifier (ID), that is an ID that does not have an IP 5Q inchlding name and key . user client pairs database 52 
address associated with it, with a CD 26. The resolution indudi name uo loca , ^ [D m femote ^ m 
occurs dynamicaUy dunng connection negotiation. 50 112, remote endpoint ID 113, initialization 114 (autostart, 
In accordance with the preferred embodiment of the on _ demand> ^ and NAr local cUcnt (:booleaD ) i 15 
invention, an API ^ provided for allowing access to VPN M ff 54 {M ^ { ^ and 
policy objects in a VPN Policy database from a GUI-type \ . m jj i 7 uji 
operations navigator (herein referred to as GUI). The API ^ n ° u ut P u ^ IP ke V Tm^Tl ^ yS 
treats each data object (see FIG. 1) as a separate database, dalabase 56 > inclu , din 8 " m P ut ID r f d a ^ data mana ^- 
where all databases together constitute a VPN Policy data- 55 ^L™? policies daubasc 58 including name 120 
base. In this way, the API allows VPN policy objects to be ISAKMP situation 121, perfect forward secrecy 122 
created, deleted, and retrieved. (:boolean), and SA refresh threshold 123 fields; data man- 
Each object in a database has a unique key for keyed agement proposal lists databases 60 and 62, including name 
reference. This key is either a name or an ID, depending or fields 124 and 125, respectively; data management proposals 
the database. An ID is an identification of a system or group 60 database 64, including name 126, transform list 128, ESP 
of systems in the VPN (e.g. An FQDN or an IPV4 subnet). transform list 129, and IPComp transform list 130; data 
All references between objects of different databases is via management transforms database 66, including name 131, 
object name. type (ESP/AH/IPComp), encapsulation mode (tunnel/ 
All databases in which objects have names support keyed transport), encryption algorithm 132, authentication algo- 
references by object name. All other databases support 65 rithm 133, DH group 134, key length, key rounds, lifetime 
keyed references by ID (i.e., ID of a specific system or group 135 and lifesize 136 fields, and IPComp info; and server 
of systems). addresses database, including external ID and a list of IP. 
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These databases are also referred to as objects, objects being IP addresses database 54 maps an ID (for example, DER 

the more general term. ASN1 distinguished name) to an IP address, as input by the 

Connections definitions database 26 holds connection user via the GUI. No verification is made via DNS or similar 

definitions. A connection definition holds information on that this mapping is correct. This mapping may be used by 

what a connection looks like and how it is made. It is used s IKE for authentication of key management security policy 

to map a subset of IP traffic to a security policy and certain 36. 

connection attributes. Since a connection definition 26 maps A se Cur ii y policy object 58 maps a connection definition 

directly to an anchor filter rule 20, a customer-defined order 26 , 0 objects used t0 define the t of protection for traffic 

between connection definitions 26 exists in the database. with ^ tQ mat connection definition< i t holds references 

Therefore, a connection definition 26 that is enabled to 1Q 61> 63 t0 data management (phase ir) negotiaUon informa . 

create connections externally (i.e., as an ISAKMP , , ° , i r . r j 

responder), can be referenced via a client ID pair (IDci/IDcr tl0 . n < that data management proposal list 64) for dynamic 

from an ISAKMP initiator) using the 'get first applicable* pO" c *es. 

function of the API in addition to the object name 82. Data management (as opposed to key management) pro- 
Connection definition 26 objects are unique with respect to P^i list 60, 62 holds a list of data management proposals 
its anchor filter rule 20. If an anchor filter rule 20 is loaded 15 "> o^er of customer preference to offer in ISAKMP 
on multiple interfaces, then that connection definition 26 initiator 18 role or to match against in ISAKMP responder 
applies to those multiple interfaces. Since no runtime or ^ mode. 

operational information is kept in the VPN policy database, Data management proposal 64 holds references for IKE 

a single, uniquely named connection definition 26 may exist 16, 17 to data management transforms 66, 

in the database and apply for all effected interfaces. When 20 Data management transform 66 holds information for IKE 

the effective remote client ID, IDci, is a non-IP type (e.g. 16, 17 on a specific ISAKMP phase II transform to offer or 

User@FQDN), the connection definition 26 is selected by match against. Phase II is an ISAKMP term for the nego- 

the 'get first applicable 5 function of the API, which uses tiation of keys to protect the actual user data (i.e. the real 

connection definition's 26 deferred selectors 22 to reference VPN connection). This is in contrast to Phase I, which is the 

a remote ID group 32 as a list of potential matches of the 25 negotiation of keys for a ISAKMP/ISAKMP connection to 

effective, non-IP type remote client IDs. protect Phase II negotiations. One aspect of the preferred 

Auser client pair object 52 is associated with a connection embodiment of the invention is that VPN connections (the 

definition 26 and is used to describe actual connections to be results of a Phase II negotiation) are based mainly on data 

initiated by this system, as distinguished from those con- endpoints, while key management connections (the results 

nections initiated by external systems. Names 110 for user 30 of Phase I negotiations) are based on connection endpoints. 

client pair objects 52 are not customer generated, but rather Key management security policy 36 is used to describe 

internally generated by the GUI by concatenating the ISAKMP Phase I connections via references 45, 47 to an 

object's connection definition 26 name 82 with a unique initiator key management proposal 42 to offer in ISAKMP 

sequence number for that connection definition 26; sepa- ^ initiator 18 mode and to a responder key management 

rated by ':L' (ConnDefName:Lseqnumber). The *L* indi- proposal 40 to match against in ISAKMP responder 19 

cates that the connection is defined Locally, as opposed to mode. 

connections defined Remotely A key management proposals 40, 42 hold references for 

(ConnDefName:Rseqnumber). The GUI/customer learns IKE 16, 17 to key management transforms 44 in order of 

these names via the 'List' or 'List Key* function of the API. ^ user preference. 

A user client pair object 52 may also contain references to Key management transforms 44 hold information for IKE 

static security association (SA) objects 46 and 48. This is the 16, 17 on a specific Phase I transform to offer or against 

case when the user client pair 52 *s connection definition 26 which to match. Pseudo-random function (prf) is an attribute 

indicates a static policy (i.e. no dynamic keying via IKE). that is negotiated by IKE. 

Deferred selectors 22 use unresolved IDs, such as user 45 Key management preshared keys database 56 maps a 

IDs, to point to a connection definition 26. This way, policy system ID or user ID to a preshared key for the purpose of 

can be established to map multiple groups of IDs to different authenticating an ISAKMP Phase I connection, when the 

security policies 58 prior to knowing the IP address of any key management security policy 36 authentication mecha- 

of the IDs. nism 103 indicates authentication via pre-shared keys. This 

All deferred selector objects 22 are referenced by a single 50 database 56 should be implemented with some sort of out of 

system-wide deferred selector list 24. This list 24 is, in turn, band encryption protection to keep the keys secret on the 

referenced by a single anchor filter rule 20 (the mobile/ system. 

Dynamic_IP users filter rule 20). A static security pair 46, 48 (one inbound, and one 

Remote ID group 32 is a customer-generated (via the outbound) is used when a given connection definition 26 

GUI) list of IDs 108 (or single ID 108) associated with a 55 indicates connections to not use IKE for key management 

group name 96. It also directly references the local ID 34, and instead use static IPSec information and keys 50. Static 

key management security policy 36, and NAT pool 38 security association pair objects 46, 48 come in two types, 

objects for this group 108 of IDs. This is the database that each with their own database: static AH SA pairs 46 and 

IKE starts with to locate key management (phase I) security static ESP SA pairs 48. Information in a static security 

policy 36, given a remote ID (IDii, if responding or IDir, if go association pair 46, 48 is similar to that of an IPSec security 

initiating). Since a single ID may map to multiple remote ID association pair. A security association pair (SA Pair) is an 

group objects 32, a customer-defined order between remote IPSec term (RFC2401) for information used in the kernal on 

ID groups 32 exist in the database. Therefore, a remote ID how protect a selected datagram (e.g. What algorithm to use, 

group 32 can be referenced on the 'get first applicable 1 what is the key, etc.) created by an ISAKMP Phase II 

function of the API based on identifier (ID). es negotiation. 

Local IDs database 34 associates a local ID (IDii when Static security association key 50 maps a reference from 

initiating, IDir when responding) with a local ID name. a static security association pair 46, 48 to the keying material 
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50 to use for a static connection. This database 50 should be 
implemented with some sort of out of band encryption 
protection to keep the keys secret on the system. 

NAT address pool database 38 lists all the external IP 
addresses 100 that can be used to NAT to/from a particular 
remote ID, Addresses from these pools 38 are used to NAT 
the local data endpoint address when a user client pair 52 
indicates NAT local client 115 and to NAT the remote data 
endpoint address when a connection definition 26 indicates 
NAT remote client 92. This is described in detail in copend- 
ing patent application Ser. No. 09/240,720. 

Server is a database 28 that is used to hide the actual 
internal server address(es) 141 behind a single external, 
globally known server ID 28. This is done by NATing the 
local data endpoint address (not shown) to one of the 
server's internal addresses 141 whenever the connection 
definition 26 indicates NAT local client 91. 

A series of 'integrity checks' or audits are performed on 
the data in the VPN Policy database to ensure correct 
operation of the VPN. These audits may be done either 
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112 must be within the associated connection definition 
selectors 83, and must be correct with respect to the asso- 
ciated connection definition granularity 86, (f) if a connec- 
tion definition's keying 88 indicates dynamic, a security 

s policy reference 35 must exist, (g) is a. connection defini- 
tion's keying 88 indicates static, all user client pairs 52 
associated with the connection definition 26 must have a 
static AH SA pair reference 53 or a static ESP SA pair 

10 reference 55, or both, (h) no static AH SA pairs 46 or static 
ESP S A pairs 48 with an encapsulation mode of transport are 
referenced by a user client pair 52 that references a connec- 
tion definition 26 with a local endpoint role 84 or remote 
endpoint role 85 of gateway, (i) no user client pair 52 can 

15 reference a connection definition 26 whose initializer 87 
indicates external only, (j) length of key in static key 50 is 
correct for the algorithm it is used for, (k) ID type fields 
found in the VPN Policy database indicates ID types con- 
sistent with those of Table 1. 



TABLE 1 

ID TYPES 



ID 







IP 


IP 


Types 






Host 




IP 


Addr 


Addr 


User @ 


ASN.l 




I/F Name 


DB Object 


Addr 


Range 


Subnet 


FQDN 


DN 


KEY__ID 


Name (FQDN) 


Conn Definition.Selectors 


X 


X 


X 








X 


User Client 
















PairClientlDs 


X 


X 


X 








X X 


UserCHcnt Pair. Remote 
















E/P ID (Dynamic 


X 






X 


X 


X 


X 


UserClient Pair.Remote 
















E/P ID (Static 


X 












X 


Deferred 
















Selector.RIDG.RID 








X 


X 


X 




RemoteldGro up. Remote 
















E/P 
















ID 


X 


X 


X 


X 


X 


X 


X 


Server 


X 


X 












Local E/P ID 


X 






X 


X 


X 


X 


Internal Server ID 


X 


X 


X 










NAT Pool ID 


X 


X 


X 










IP Ad dress .inld 


X 






X 


X 


X 




IP Ad dress .outld 


X 














Pre-sharcd Key.id 


X 






X 


X 


X 





during policy creation and updating, or during runtime, 
when the data is acted upon. These audits include general 
audits and audits specific to a database. General audits 
include (a) ensuring objects referenced by other objects 
exist, (b) fields are valid, (c) object is unique with respect to 
its key (name or ID), and (d) indicated protocols and 
algorithms are supported. 

Audits specific to a database include (a) no connection 
definition 26 can be updated or deleted while an active 
connection exists for that connection definition, (b) no 
proposal 64 is used that has an encapsulation mode 127 of 
transport when either of the used connection definition 
endpoint roles 84,85 indicates gateway, (c) if a connection 
definition 26 references a deferred selector 22, then the 
connection definition's granularity 86 for remote ID must 
indicate that the source of the connection's client IDs be 
from the client ID pair, and the remote endpoint role 85 must 
be host, (d) all connection definition selectors 83 must 
indicate IP-types (IPV4 or IPV6; address, subnet, or range), 
(e) user client pair's local client ID 111 and remote client ID 



In accordance with the preferred embodiment of the 
model, an API is defined for the purpose of creating, 

50 updating, deleting, and retrieving database objects in the 
VPN Policy database. Specific functions of the API include 
get_by_name (to retrieve objects from databases keyed by 
a name), get_by_id (to retrieve objects from databases 
keyed by an ID), get_first_applicable (to retrieve the first 
object that is associated with the input ID information; used 

55 for connection definitions 26 and remote endpoint ID groups 
32), create, update, delete, list (to list all objects of a 
database in their entirety), and list_key (to list only the keys, 
i.e. Name or ID, of all objects of a database). The API is used 
by the GUI to create and update VPN security policy and by 

60 the IKE/VPN Mgr functions 16, 17 when creating and 
managing VPN connections. 

A connection is a relationship between two IPSec end- 
points 18, 19 that protect a specific set of IP traffic between 
them in a pre-defined manner, according to each endpoint's 

65 VPN policy. 

Connections are created from connection definitions 26. 
Connection definitions 26 are user-specified objects that are 
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associated one-to-one with a user-specified filter rule when 
that filter rule's action is 'Protect with IPSec\ This filter rule 
is called an anchor filter 20 rule. Anchor filter rules 20 are 
used to protect a subset of IP traffic according to a security 
policy 58. Therefore, all connections created from a specific 
a specific connection definition will have the same security 
policy 58. The exception to this is dynamically assigned IP 
addresses for remote, mobile users with dynamically- 
assigned IP addresses. For these cases, a single anchor filter 
rule 20 can be associated with multiple connection defini- 
tions 26. 

Because of this association of a single anchor filter rule 20 
to a single connection definition 26, and the fact that anchor 
filter rules 20 are ordered, connection definitions 26 have an 
inherent ordering among themselves. The IP traffic that is 
associated with a connection definition is specified by its 
selectors 83, which are copied from its associated anchor 
filter rule 20 when the anchor filter rule is loaded onto the 
systems interface (i.e. becomes active). Aset of selectors has 
the following attributes: 

Local IP address (single,range,addr+mask,*) 

Remote IP address (single,range,addr+mask,*) 

Transport protocol (value,*) 

Local port (value,*) 

Remote port (value,*) 

In order to create a connection from a connection defini- 
tion 26, a client ID pair is needed. A client ID pair is made 
of two client IDs, a local client ID and a remote client ID. 
Like selectors 83, they are used to define a subset of IP 
traffic, for example all TCP traffic to or from host A from or 
to any host on subnet B. A client ID has the following 
attributes: 

ID type 

IPv4 address 
IPv6 address 

FQDN (for example, foo.bar.com) 

User FQDN (for example, piper@foo.bar.com) 

IPv4 subnet (addr & mask) 

IPv4 range (1st addr & last addr) 

IPv6 subnet (addr & mask) 

IPv6 range (1st addr & last addr) 

DER ANSI dist name 

Physical interface or PPP profile name 

(implementation-specific) 
0 (meaning don't care) 
ID value 

Protocol (specific value, or 0 meaning don't care) 
Port (specific value, or 0 meaning don't care) 
A client ID pair, in conjunction with a connection defi- 
nition 26 (and it's related information such as security 
policy, etc.), provides all the information needed to create a 
connection. Thus, 

connection definition +client ID pair ^connection. 
The client ID pair is obtained from a user-specified user 
client pair 52, for the case of startable, scheduled 
on-demand, or autostart connections; or from a remote 
system via IKE, for responder-mode connections (i.e. IDci/ 
IDcr). On-demand connections use data in the 'demanding 1 
IP packet to define a client ID pair. 

One or more connections can be created from a single 
connection definition 26, depending on that connection 
definition's connection granularity 86. Connection granular- 
ity 86 defines what subset of the IP traffic that is associated 
with this connection definition will be associated with each 
connection created from this connection definition 26. It 
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does this by specifying the source of the different attributes 
of a connection's local client ID and remote client ID. For 
each attribute, connection granularity 86 specifies the source 
as taken directly from the connection definitions selectors 83 
(* filter'); a single value taken from the client ID pair 
(* single'); or taken directly from the client ID pair ('client'). 

By ensuring that all connections created from a connec- 
tion definition 26 derive their local and remote client IDs in 
this consistent manner, and by ordering connections with 
more specific masked IP address (source address priority) 
ahead of those with less specific masked IP addresses, a 
predictable and non-conflicting ordering of connections can 
be derived when building the filter rules (SPD entries) for 
the IP stack. The exception to this is the last selection (that 
is, taken directly from client ID pair). This selection is used 
mostly for creating connections in responder-mode, since 
the connection granularity 86 of the Client ID pair of an 
initiating remote endpoint may not be known ahead of time. 
This, however, allows creation of connections that are not 
orderable in a predictable and non-conflicting manner. 
Therefore, this situation must be handled dynamically (that 
is, when loading the filter rules (SPD entry) for this con- 
nection to the kernel or, preferably, when IKE 16, 17 is 
negotiating the Phase II Security Associations) to ensure that 
a candidate connection does not adversely overlap with an 
existing connection. 

Referring to Table 2, local and remote endpoint roles are 
described. 

TABLE 2 
LOCAL AND REMOTE ENDPOINT ROLES 
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Local 



Remote 



Effect on Connection Granularity 



Gateway 


Gateway 


No changes 


Gateway 


Host 


Remote ID must be specific value 


Host 


Gateway 


Local ID must be specific value 


Host 


Host 


Local & Remote IDs must be specific 






values 



Along with connection granularity 86, another attribute of 
a connection definition 26 is local endpoint role 84 and 
remote endpoint role 85. A role in this sense is either a 
security gateway (GW) or a host (H). The local endpoint is 
the system that will encrypt outbound traffic and decrypt 
inbound traffic. Conversely, the remote endpoint is the 
system that will decrypt and encrypt that traffic. The values 
of these two attributes 84, 85 effect the allowable values for 
the connection definition connection granularity 86. The 
values of these two attributes 84, 85 also effect valid 
negotiable IP Sec transforms, in that if the local or remote 
role 84, 85, respectively, is gateway, no transform 66 may be 
negotiated that has an encapsulation mode of transport. 

A connection's client IDs are generated using client ID 
pairs, local and remote endpoint roles 84, 85, connection 
granularity 86 and the connection definition's selectors 83. 
This is done by: 

1. Checking the connection definition selectors 83 for 
which granularity 86 indicates 'filter' against the local 
endpoint role 84 and remote endpoint role 85, as shown 
in Table 2; and 

2. Checking the client ID pair (either a user client pair 52 
or an ISAKMP IDci/IDcr) to ensure it is within the 
bounds of the connection definition selectors 83; and 

3. Checking the client ID pair against the connection 
definition granularity 86 to ensure it is of the correct 
granularity (that is, granularity values of 'single' must 
correspond to single values in the client ID pair); and 
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4. Checking those attributes of the client ID pair for which a program storage or memory device such as a solid or fluid 
the granularity 86 indicates 'single* or 'client' against transmission medium, magnetic or optical wire, tape or disc, 
the local endpoint role 84 and remote endpoint role 85, or the like, for storing signals readable by a machine for 
as shown in Table 2; and controlling the operation of a computer according to the 

5. Using the client ID pair and the connection definition s method of the invention and/or to structure its components 
selectors 83 to generate the connection client IDs in accordance with the system of the invention, 
according to the connection granularity; 'client' or Accordingly, the scope of protection of this invention is 
'single' indicate the value comes from the client ID limited only by the following claims and their equivalents, 
pair, 'filter' indicates the value comes from the con- We claim: 

nection definition selectors 83. 10 1. A policy database system for managing security 

The resulting connection client IDs are then used to create objects, comprising: 

the filter rules (SPD entry) for this connection in the kernal. a deferred selectors component; 

A . .« n ' a » * a connection definition; 
Advantages over the Prior Art 

15 a user client pair; 

It is a further advantage of the invention that there is a mamial connection component; 

provided a system and method for creating, maintaining, t . , . 

j , .. j • . ,, ONT v u- * a remote connection endpoint attributes component 

deleting and retrieving VPN policy objects. . , , _ r . / 

° ° .... including a phase I processing component; and 

It is a further advantage of the invention that there is T _ 

provided a system and method for enabling acceptance of 20 a ph ™ " P rocessm S com P onent ; 

previously unknown IDci/IDcr values from a remote system. said connection definition having a zero or one reference 

c j , c *u f tu * tu *„ relationship with said deferred selectors component, a 

It is a further advantage of the invention that there is r c . . . , i * 

•j j t j 7l j ur a. a ' zero or more reference relationship with said user client 

provided a system and method enabling dynamic generation, , c r , . ... 

f , . ' . c u . , Tr ,e ,i pair, and a zero or one reference relationship with said 

load, and management of multiple IPSec filter rules. v ' . *\. 

° . phase II processing component; said user client pair 

It is a further advantage of the invention that there is 25 mrt her having a zero or one reference relationship with 

provided a system and method enabling ISAKMP phase II sajd manual connection component; and said deferred 

driven phase I connections. selectors component having a one and only one refer- 

It is a further advantage of the invention that there is e nce relationship with said remote connection 

provided a system and method enabling handling of remote attributes component. 

initiating hosts with dynamically assigned IP addresses with 2. The policy database system of claim 1 further for 

differing security policy requirements. enabling acceptance at a responder node of a previously 

It is a further advantage of the invention that there is unknown client ID pair from an initiator node, said connec- 

provided flexibility in policy definition in the areas of tion definition comprising indicia for determining if said 

dynamically-assigned IP addresses, remotely-defined 35 unknown client pair is acceptable to said responder node and 

ISAKMP client IDs (IDci/IDcr), and separation of ISAKMP said phase II processing component comprising a policy for 

Phase I (key management) policy information from negotiating said unknown client ID pair. 

ISAKMP Phase II (data management) policy information. 3. The policy database system of claim 1 further for 

It is a further advantage of the invention that there is enabling dynamic generation, loading and management of 
provided a data model for representing and abstracting 40 multiple connection filters, said connection definition being 
IPSec/ISAKMP-based VPN configuration information for selectable selectively by said user client pair or a client ID 
an IPSec-capable computer system in a virtual private received from a remote initiator node for identifying 
network that (1) allows for each customer-generated pertinent granularity attributes defining the subset of data- 
customer-ordered security policy database (SPD) entry, mul- grams that can be associated with any one connection 
tiple VPN connections to be dynamically established (these 45 instantiated from said connection definition, 
connections may or may not have been previously defined); The policy database system of claim 1 further for 
(2) allows for a data-security-policy -driven approach to enabling ISAKMP phase II driven phase I connections, said 
rekeying (via IKE) where (a) the key management connec- remote connection endpoints attributes further comprising a 
tion (i.e. the secure connection used to exchange keying remote endpoint identifier and a reference pointer for asso- 
material for the data connections) is created and maintained 50 ciatin g said remote endpoint identifier with a phase I nego- 
by security policy and on an on-demand basis by data tiation policy in said phase I processing component, 
connection activity, and (b) the key connection security 5 - Tlie policy database system of claim 1 further for 
policy is determined solely by the identity of the remote enabling secure connection by a responder node to a remote 
connection endpoint; (3) allows for dynamically establish- initiating host with dynamically assigned IP address, further 
ing VPN connections with different security policies and 55 comprising: 

other attributes, based solely on an unfixed IP address (e.g. - an anchor filter for defining datagrams that may be 

a user ID) — these connections may or may not have been associated with remote hosts using dynamically 

previously defined. This aspect is used for supporting sys- assigned IP addresses; 

terns with dynamically-assigned IP addresses that wish to said deferred selectors component further providing a one 

establish a VPN connection with the local system. 60 t0 many mapping from said anchor filter to said con- 

nection definitions. 

Alternative Embodiments fi A method fof managing a policy databasc> said database 
It will be appreciated that, although specific embodiments including a deferred selectors component, a connection 
of the invention have been described herein for purposes of definition, a user client pair, a manual connection 
illustration, various modifications may be made without 65 component, a remote connection endpoint attributes corn- 
departing from the spirit and scope of the invention. In ponent including a phase I processing component; and a 
particular, it is within the scope of the invention to provide phase II processing component, comprising the steps of: 
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maintaining a zero or one reference relationship of said 
connection definition with said deferred selectors com- 
ponent; 

maintaining a zero or more reference relationship of said 
connection definition with said user client pair; 

maintaining a zero or one reference relationship of said 
connection definition with said phase II processing 
component; 

maintaining a zero or one reference relationship of said 
user client pair with said manual connection compo- 
nent; and 

maintaining a one and only one reference relationship of 
said deferred selectors component with said remote 
connection attributes component. 

7. The method of claim 6, further for enabling acceptance 
at a responder node of a previously unknown client ID pair 
from an initiator node, comprising the further steps of: 

determining from connection definition indicia if said 
unknown client pair is acceptable to said responder 
node, and if so 

obtaining from said phase II processing component a 
policy for negotiating said unknown client ID pair. 

8. The method of claim 6, further for enabling dynamic 
generation, load and management of multiple connection 
filters, comprising the further steps of: 

obtaining from a said connection definition, selectively 
selected by said user client pair or a client ID pair 
received from a remote initiator node, granularity 
attributes defining the subset of datagrams that can be 
associated with any one connection instantiated from 
said connection definition. 

9. The method of claim 6, further for enabling ISAKMP 
phase II driven phase I connections, comprising the further 
steps of: 

associating a remote endpoint identifier in said remote 
connection endpoints attributes with a phase I negotia- 
tion policy in said phase I processing component. 

10. The method of claim 6, further for enabling secure 
connection by a responder node to a remote initiating host - 
with dynamically assigned IP address, further comprising 
the steps of: 

providing an anchor filter for defining datagrams that may 
be associated with remote hosts using dynamically 
assigned IP addresses; and 

said deferred selectors component further providing a one 
to many mapping from said anchor filter to said con- 
nection definitions. 

11. A program storage device readable by a machine, 
tangibly embodying a program of instructions executable by 
a machine to perform method steps for managing a policy 
database, said database including a deferred selectors 
component, a connection definition, a user client pair, a 
manual connection component, a remote connection end- 
point attributes component including a phase I processing 
component; and a phase II processing component, said 
method steps comprising: 

maintaining a zero or one reference relationship of said 
connection definition with said deferred selectors com- 
ponent; 

maintaining a zero or more reference relationship of said 
connection definition with said user client pair; 

maintaining a zero or one reference relationship of said 
connection definition with said phase II processing 
component; 

maintaining a zero or one reference relationship of said 
user client pair with said manual connection compo- 
nent; and 
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maintaining a one and only one reference relationship of 
said deferred selectors component with said remote 
connection attributes component. 

12. An article of manufacture comprising: 

a computer useable medium having computer readable 
program code means embodied therein for managing a 
policy database, said database including a deferred 
selectors component, a connection definition, a user 
client pair, a manual connection component, a remote 
connection endpoint attributes component including a 
phase I processing component; and a phase II process- 
ing component, the computer readable program means 
in said article of manufacture comprising: 

computer readable program code means for causing a 
computer to effect maintaining a zero or one reference 
relationship of said connection definition with said 
deferred selectors component; 

computer readable program code means for causing a 
computer to effect maintaining a zero or more reference 
relationship of said connection definition with said user 
client pair; 

computer readable program code means for causing a 
computer to effect maintaining a zero or one reference 
relationship of said connection definition with said 
phase II processing component; 

computer readable program code means for causing a 
computer to effect maintaining a zero or one reference 
relationship of said user client pair with said manual 
connection component; and 

computer readable program code means for causing a 
computer to effect maintaining a one and only one 
reference relationship of said deferred selectors com- 
ponent with said remote connection attributes compo- 
nent. 

13. A policy database system for managing security 
objects and enabling ISAKMP phase II driven phase I 
connections, comprising: 

a deferred selectors component; 

a connection definition; 

a user client pair; 

a manual connection component; 

a remote connection endpoint attributes component 
including a phase I processing component; and 

a phase II processing component; 

said connection definition having a zero or one reference 
relationship with said deferred selectors component, a 
zero or more reference relationship with said user client 
pair, and a zero or one reference relationship with said 
phase II processing component; said user client pair 
further having a zero or one reference relationship with 
said manual connection component; and said deferred 
selectors component having a one and only one refer- 
ence relationship with said remote connection 
attributes component; and 

said remote connection endpoints attributes further com- 
prising a remote endpoint identifier and a reference 
pointer for associating said remote endpoint identifier 
with a phase I negotiation policy in said phase I 
processing component. 

14. A method for managing a policy database and 
enabling ISAKMP phase II driven phase I connections, said 
database including a deferred selectors component, a con- 
nection definition, a user client pair, a manual connection 
component, a remote connection endpoint attributes com- 
ponent including a phase I processing component; and a 
phase II processing component, comprising the steps of: 
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maintaining a zero or one reference relationship of said 
connection definition with said deferred selectors com- 
ponent; 

maintaining a zero or more reference relationship of said 
connection definition with said user client pair; s 

maintaining a zero or one reference relationship of said 
connection definition with said phase II processing 
component; 

maintaining a zero or one reference relationship of said 1Q 
user client pair with said manual connection compo- 
nent; 

maintaining a one and only one reference relationship of 
said deferred selectors component with said remote 
connection attributes component; and ^ 
associating a remote endpoint identifier in said remote 
connection endpoints attributes with a phase I negotia- 
tion policy in said phase I processing component. 
15. A program storage device readable by a machine, 
tangibly embodying a program of instructions executable by 20 
a machine to perform method steps for managing a policy 
database and enabling ISAKMP phase II driven phase I 
connections, said database including a deferred selectors 
component, a connection definition, a user client pair, a 



manual connection component, a remote connection end- 
point attributes component including a phase I processing 
component; and a phase II processing component, said 
method steps comprising: 

maintaining a zero or one reference relationship of said 
connection definition with said deferred selectors com- 
ponent; 

maintaining a zero or more reference relationship of said 
connection definition with said user client pair; 

maintaining a zero or one reference relationship of said 
connection definition with said phase II processing 
component; 

maintaining a zero or one reference relationship of said 
user client pair with said manual connection compo- 
nent; 

maintaining a one and only one reference relationship of 
said deferred selectors component with said remote 
connection attributes component; and 

associating a remote endpoint identifier in said remote 
connection endpoints attributes with a phase I negotia- 
tion policy in said phase I processing component. 
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